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Background Information 

0.1 INTRODUCTION 

This is the second edition of API 1 130. The first edition of 
API 1 130 was published in 1995. Since that time, the users of 
this information (e.g., pipeline operators, system developers, 
system integrators and the regulators) have had an opportu- 
nity to employ the information provided and to evaluate the 
publication. They have offered suggestions for changes to 
improve the document. 

Since publication, API 1 130 has also been referenced in 
the federal pipeline safety regulations (see 0.2 below). In 
addition, APT requires that API publications and standards be 
reconfirmed on a regular basis. Therefore, this second edition 
of API 1 130 has been modified to include suggested improve- 
ments and rectify inconsistencies and errors. 

Computational Pipeline Monitoring (CPM) is a term that 
was developed to refer to algorithmic monitoring tools that 
are used to enhance the abilities of a pipeline controller to 
recognize hydraulic anomalies that may be indicative of a 
pipeline leak or commodity release. In the past, these CPM 
systems have been generally called leak detection systems. 
However, pipeline leak detection can be accomplished by a 
variety of techniques such as: aerial/ground line patrol; third 
party reports; inspections by company staff; hydrocarbon 
detection sensors; SCADA monitoring of pipeline conditions 
by pipeline controllers; and software based monitoring. Con- 
sequently, the term CPM was developed to specifically cover 
leak detection using algorithmic tools. 

The original edition of API 1 130 (1995) was written by the 
APT Computational Pipeline Monitoring Task Force which 
was formed in April 1 994. The purpose of the group was to 
develop an API publication for CPM as it is used in the liq- 
uids pipeline industry. This update of API 1130 (2002) has 
been written by a Task Force of the API Cybernetics Sub- 
Committee and includes input from all committee members 
as well as a broad community of CPM system developers and 
system integrators. 

0.2 REGULATORY CONSIDERATIONS 

Users of APT 1 130 must be familiar with the regulations that 
cover hazardous liquid pipelines. These regulations may apply 
at municipal, state or federal levels. For example, since the first 
edition of API 1 1 30, the Department of Transportation's 
Office of Pipeline Safety has included a reference to API 1130 
in 49 CFR Part 1.95. Those regulations will likely be subject to 
updating within the life of this second edition of API 1 130, so 
the exact references are not included in this document. 

In regulations, a reference may be directly to CPM or may 
use the words "leak detection" or aspects of "integrity man- 



agement." A CPM or "leak detection" system may be man- 
dated by future regulations or by operating restrictions. The 
reference may also be indirect as in the regulatory require- 
ment for the closing of remote valves (or activation of flow 
restricting devices) where a CPM system may be used as one 
of the triggers for that activation, particularly in "high conse- 
quence" areas. 

CPM systems may be employed when the requirements 
state: 

a. A pipeline operator must have a means to detect leaks on 
its pipeline system. 

b. The pipeline operator must evaluate the capability of its 
leak detection means and modify it as necessary to provide a 
sufficient level of protection (i.e., the CPM may be adjusted 
to account for the operational mode or characteristics of the 
pipeline segment including shut-in. Ideally, factors, such as 
length and size of the pipeline; type of product carried; the 
pipeline's proximity to high consequence areas; the swiftness 
of leak detection; the location of nearest response personnel; 
the pipeline's leak history; and risk assessment results, must 
be considered). 

This document provides guidance that will be helpful in 
addressing regulatory requirements but does not claim to be 
all inclusive in that regard. The pipeline operator will need to 
understand the regulations and work with the regulators and 
their agents to satisfy all requirements. 

1 Scope 

1.1 PURPOSE 

This publication focuses on the design, implementation, 
testing and operation of CPM systems that use an algorithmic 
approach to detect hydraulic anomalies in pipeline operating 
parameters. The primary purpose of these systems is to pro- 
vide tools that assist pipeline controllers in detecting com- 
modity releases that are within the sensitivity of the 
algorithm. It is intended that the CPM system would provide 
an alarm and display other related data to the pipeline control- 
lers to aid in decision-making. The pipeline controllers would 
undertake an immediate investigation, confirm the reason for 
the alarm and initiate an operational response to the hydraulic 
anomaly when it represents an operational upset or commod- 
ity release 

The purpose of this publication is to assist the pipeline 
operator in identifying issues relevant to the selection, imple- 
mentation, testing, and operation of a CPM system. This doc- 
ument be used in conjunction with other API publications and 
applicable regulations. 
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1.2 CONTENTS 

This publication includes definitions, source and reference 
documents, concepts of data acquisition, discussion of design 
and operation of a pipeline as related to CPM, field instru- 
mentation for CPM purposes, alarm credibility, pipeline con- 
troller response, incident analysis, record retention, 
maintenance, system testing, training, considerations for set- 
ting alarm limits, trending and recommendations for data pre- 
sentation. The relationship between the pipeline controller 
and the CPM system is also discussed. 

1.3 SCOPE LIMITATIONS 

This publication is limited in scope to single-phase, liquid 
pipelines. It is recognized that no one particular methodology 
or technology may be applicable to all pipelines because each 
pipeline system is unique in design and operation. In addi- 
tion, detectable limits are difficult to quantify because of the 
unique characteristics presented by each pipeline. Limits 
must be determined and validated on a system-by-system and 
perhaps a segment-by-segment basis. Figure B-J (along with 
the discussion in Appendix B) provides a starting point for 
understanding where the practical detection limit of commod- 
ity releases starts. This publication is not all inclusive. The 
reader must have an intimate knowledge of the pipeline and 
may have to refer to other publications for background or 
additional information. 

CPM is intended usually as a tool to be used by the pipe- 
line controller in the safe operation of the pipeline. Effective 
operation of a pipeline requires that the pipeline controller be 
familiar with the pipeline and the tools at their disposal. CPM 
is not currently intended to replace human judgement and 
intervention in the shutdown of the affected pipeline seg- 
ments) and the closure of remote control valves or directing 
field staff to close hand operated valves on the pipeline. 

This publication complements but does not replace other 
procedures for monitoring the integrity of the line. CPM sys- 
tems, as well as other commodity release detection tech- 
niques, have a detection threshold below which commodity 
release detection cannot be expected. Application of the 
information in this publication will not reduce the threshold at 
which a commodity release can be detected. For example, 
trained pipeline controllers analyzing SCADA-presented 
operating data can be effective at detecting certain sizes (i.e., 
larger) commodity releases. Third-party reports, pipeline 
patrols, and employee on-site examinations can also be effec- 
tive procedures when used to verify the integrity of the pipe- 
line within their applicability range. 

Note: This publication is in keeping with standard industry practice 
and commonly used technology; however, it is not intended to 
exclude other effective commodity release detection methods. 



1.4 TRANSPORTATION SYSTEMS 

This publication is written for liquid onshore or offshore 
trunkline systems but much of this content may be applicable 
to other piping systems such as selected gathering systems, 
production flow lines, marine vessel loading/unloading, and 
tank terminaling operations. CPM has typically been applied 
to steel pipeline systems but may be applied to pipelines con- 
structed of other materials such as PVC, polyethylene, fiber- 
glass, and concrete. The successful application of CPM may 
be limited by the characteristics of these other materials. 

Pipeline systems vary widely in their physical characteris- 
tics including: diameter, length, pipe wall thickness, internal 
roughness coefficient, pipe composition, complexity of pipe 
networking, pipeline topology, pump station configuration, 
and instrumentation (quality, accuracy, placement). These 
same pipeline systems can also be categorized by operational 
factors such as: flow rate, magnitude and frequency of rate/ 
pressure fluctuations, blending, batching, batch stripping 
schemes, product type, viscosity, density, sonic velocity, bulk 
modulus, vapor pressure, pressure, temperature, and heat 
transfer. The CPM methodology selected must be evaluated 
against what characteristics of the pipeline are known and 
what is required by the methodology to provide acceptable 
results. Most CPM technologies have not thus far proven 
themselves capable of providing satisfactory CPM operation 
during periodic or permanent slack line conditions. If this 
condition exists in a particular pipeline, then the CPM selec- 
tion criteria for that pipeline will need to consider that operat- 
ing condition. 

2 References 

2.1 REFERENCES CITED HEREIN 

The following standards, codes, and specifications are 
cited herein: 

API 

RP 1 149 Pipeline Variable Uncertainties and Their 

Effects on Leak Detectability 

RP1155 Evaluation Methodology for Software 

Based Leak Detection Systems 

RP 1 161 Guidance Document for Qualification of 

Liquid Pipeline Personnel August 2000 

2.2 OTHER APPLICABLE REFERENCES 

API 

RP 1 1 13 Developing a Pipeline Supervisory Control 

Center 
Manual of Petroleum, Measurement Standards (instruments 

and trends) 
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CSA 1 

CSA-Z662- 
M99 

DOT 2 

49 

ISO 3 
ISO 9000 



Oil and Gas Pipeline Systems, Appendix 
E, "Recommended Practice for Leak 
Detection" 



Code of Federal Regulations Part 195 



Quality Management Family of Standards 
and Guidelines 



3 Definitions 

Definitions for all the important words or phrases used in 
this publication are listed and described in the glossary, 
Appendix A of the document. 

4 Technical Overview 

4.1 METHODOLOGIES 

This section discusses the generic types of CPM methodol- 
ogies, provides a list of desirable CPM features and mentions 
important issues concerning the fluids transported. 

The SCADA and CPM systems present field data and cal- 
culated information for the pipeline controller to evaluate and 
take appropriate action. The degree of complexity in process- 
ing field data varies from simple comparisons of a particular 
parameter relative to a threshold limit to more extensive anal- 
ysis of multiple parameters with interlocking and/or dynamic 
threshold limits. All CPM algorithms are based on certain 
design and implementation assumptions to: 

a. Compensate for pipeline operational and/or configuration 
uncertainties. 

b. Reach an acceptable compromise between accuracy and 
speed of solution. 

These assumptions need to be completely met for a suc- 
cessful CPM implementation. 

Methods that use sensors directly or indirectly to detect 
commodity releases can be classified as EXTERNALLY 
BASED or INTERNALLY BASED (respectively). 

4.1.1 Externally Based Leak Detection Systems 

This publication does not consider externally based pipe- 
line leak detection systems that operate on the non-algorith- 
mic principle of physical detection of an escaping 
commodity. In these systems, the local detector sends an 
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alarm signal to the Control Center for display and annuncia- 
tion. Externally based methods are excluded from the discus- 
sion of CPM because they do not meet the requirement of 
performing computation on field parameters for inferring a 
commodity release. 

The following are common types of externally based sys- 
tems or devices: 

a. Fiber optic hydrocarbon sensing cables. 

b. Dielectric hydrocarbon sensing cables. 

c. Acoustic emissions detectors. 

d. Hydrocarbon vapor (gas) sensors (including those with 
vapor pick-up tubes). 

4.1.2 Internally Based CPM Systems 

CPM systems that are internally based utilize field sensor 
outputs that monitor internal pipeline parameter(s). The par- 
ticular methodology may utilize some or all of the measured 
data such as: pressure, temperature, viscosity, density, flow 
rate, product sonic velocity, and product interface location. 
These inputs are then used for inferring a commodity release 
by manual or electronic computation. 

A brief description of each of the common CPM methods 
is included in Appendix C. The following describes the types 
of CPM internally based methodologies: 

a. Line balance. 

b. Volume balance. 

c. Modified volume balance. 

d. Compensated mass balance. 

e. Real time transient model. 

f. Pressure/flow monitoring. 

g. Acoustic/negative pressure wave, 
h. Statistical analysis. 

Each CPM method has its strengths and limitations. For 
example, some CPM methods are more sensitive to measure- 
ment repeatability and drift, while other approaches may 
require extensive configuration efforts and tuning. No one tech- 
nology has been proven suitable for all pipeline applications. 
Multiple CPM systems may be employed to provide a CPM 
that can more broadly cover the pipeline operating conditions. 

4.2 SELECTION CRITERIA 

Each CPM methodology contains different combinations 
of features with varying degrees of capability and sophistica- 
tion. CPM performance is contingent on the interrelationship 
of many factors, such as measurement capabilities, communi- 
cations reliability, pipeline operating condition, and product 
type. Under appropriate circumstances, commodity release 
detection will benefit by employing multiple CPM techniques 
or applications for validation or redundancy. The indepen- 
dence of parameters used in some methodologies potentially 



API 1130 



allows for independent validation or redundancy. The follow- 
ing is a list of desirable CPM features and functionality. 

The CPM features listed below are not in any particular 
order nor is there any attempt to weight the importance of 
each. Jt must be noted that no one methodology or particular 
application possesses all of these features and certain features 
will be more appropriate for specific pipeline systems. A 
CPM system must have at least one of these features. 

The CPM system may: 

a. Possess accurate commodity release alarming. 

b. Possess high sensitivity to commodity release. 

c. Allow for timely detection of commodity release. 

d. Require minimal software configuration and tuning. 

e. Perform its CPM functions with existing sensors and 
instruments (or does not have special or additional require- 
ments for instrumentation). 

f. Be minimally impacted by communication outages or by 
data failures. 

g. Accommodate complex operating conditions, 
h. Be available during transients. 

i. Be configurable to complex pipeline networks, 
j. Perform an imbalance calculation on meters at one instant 
in time. 

k. Possess dynamic alarm thresholds. 
I. Possess dynamic liquid pack constant. 
m. Accommodate commodity blending, 
n. Account for heat transfer. 

o. Provide the pipeline system's real-time pressure profile, 
p. Accommodate intermittent or permanent slack line condi- 
tions (avoiding alarms and not totally disabling all segments 
of the pipeline during the event). 
q. Accommodate all types of liquids. 

r. Identify leak location with appropriate mile post locations 
or the nearest station. 

s. Have the ability to display pressure history versus time for 
each line pressure location along a pipeline. 
t. Provide for automatic and manual data substitution during 
periods of data non-availability (e.g., communication outage, 
measurement failure, maintenance, etc.). 
u. Provide composite indication of data attributes associated 
with supporting field inputs and calculated data, 
v. Minimize the number of alarms by requiring supporting, 
and preferably independent, commodity release confirmation. 
w. Identify the leak rate. 

x. Accommodate commodity measurement and inventory 
compensation for various correction factors (temperature, 
pressure, density, meter factor). 

y. Provide batch tracking with interface location, be able to 
compute bulk modulus, and perform inventory compensation. 
z. Perform calculations quickly using data immediately as it 
becomes available. 



aa. Validate commodity release alarms using redundant anal- 
ysis within the same method as well as redundant analysis 
between methods. 

ab. Accommodate pump start-ups/shutdowns, valves open- 
ing/closing, and other normal operational functions without 
generating alarms. 

ac. Account for effects of drag reducing additive. 

ad. Offer efficient field and Control Center support. 

ae. Contain a leak probability analyzer to weigh all of the 
components of a leak (linepack loss, pressure/flow deviation, 
meter shortage) to assist a pipeline controller in making a leak 
declaration. 

af. Possess ability to allow alarms to be integrated into the 
pipeline controller's alarm processing. 

ag. Possess audit trails of CPM actions taken by pipeline con- 
trollers and allow saving of historical data. 

ah. Have the ability to return to normal detectability limits 
rapidly after data or computer service is restored or after an 
unscheduled interruption. 

ai. Have the ability to provide various types of warnings and 
alarms for example warnings or alarms on data failure or 
unusual operating conditions that indicate the cause is not a 
commodity release. 

aj. Provide an alarm under all operating conditions and will 
not be disabled or turned off automatically regardless of 
circumstances. 

ak. Have the ability to automatically self test without affect- 
ing performance while the test is underway. 

API Publ 1155 can be consulted for additional details on 
CPM performance criteria. 

4.3 COMMODITY PROPERTIES 

Commodity properties must be considered when the CPM 
methodologies that consider fluid properties are employed. 
For these methodologies to work properly, the fluid must be 
in fully liquid phase or in a homogenous mixed phase so that 
it can be mathematically characterized. These are typical 
Newtonian fluids, which comprise most crude oils and 
refined products. These fluids may also be characterized via 
their density and bulk modulus, which are independent of vis- 
cosity. Other fluids, such as high paraffin crude oils or heavy 
crudes that may be highly viscous, may exhibit non-Newto- 
nian fluid characteristics. These fluids may be mathematically 
represented but only by using complex equations. If the fluid 
is in a transient-composition mixed phase situation, then the 
CPM approach must be able to accommodate the unusual 
commodity properties. Highly volatile liquids (HVLs) are in 
liquid phase if temperature and pressure are sufficient to 
maintain the fluid above the critical point. HVL liquids are 
more compressible than crude oils, thereby making it more 
difficult for some CPM approaches to discern hydraulic 
anomalies from normal pipeline operations. 
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5 Technical Details 

5.1 FIELD INSTRUMENTATION 

Aspects of field hardware are discussed in this section. 
Sensor and instrument data must be sent from the field sites to 
the CPM system for computation or other usage. 

This portion of the publication defines good operating 
practice in the design and maintenance of the field instrumen- 
tation necessary to adequately support a CPM system. 

API Publ l 149 Pipeline Variable Uncertainties and Their 
Effects on Leak Detectability discusses the importance of 
instrumentation to CPM performance. The software develop- 
ers or providers may also advise an operator on what instru- 
ments influence the capabilities of the CPM methodology and 
what effects additional or upgraded instrumentation will have 
on their system. The calculations of API Publ 1 149 can dem- 
onstrate that inadequate and inaccurate instrumentation 
reduces CPM effectiveness, and the calculations can be used 
to determine where the most cost effective improvements can 
be made. Such analysis may be used repeatedly over the life 
of the pipeline system to achieve incremental performance 
improvement. 

Note: Different CPM methodologies require varying levels and 
types of instrumentation. Instrumentation costs may vary signifi- 
cantly for each method. Some methodologies may have specialized 
instrumentation needs. A operator may want to consider CPM 
instrument best practices (equipment and installations methods — for 
example, using buried temperature probes to avoid ambient factors), 
installation of density and/or viscosity monitors at injection points 
where fluid properties are variable and installation of additional 
pressure sensors at intermediate locations. 

5.1.1 Selection of Instrumentation 

Ranges and specifications should be carefully matched to 
pipeline operating design, pressure, flow, temperature, den- 
sity, etc. to make best use of the instrument manufacturer's 
stated accuracy and linearity. Because instrument accuracy is 
generally stated in terms of percent of full range, the smallest 
available range greater than the desired range is the preferred 
choice. There is no value in overspecification of instrumenta- 
tion accuracy if CPM performance will be limited by the 
instrumentation loop accuracy, or repeatability and resolution 
of the SCADA system. One such limitation may be imposed 
by the resolution, measured in bits, of the analog-to-digital 
(A/D) conversion hardware, as shown in the following table. 



A/DBits 


% Resolution 


8 


0.4 


10 


0.1 


12 


0.025 


16 


0.0015 



5.1.2 Installation of Instrumentation 

The quality of instrument data can affect the CPM system. 
Instruments should be installed in accordance with API RP 
550, manufacturer's recommendations and applicable indus- 
try codes and standards. The placement of instrumentation in 
relation to the process equipment is important, and should be 
carefully designed with due consideration to variations in 
operating conditions. Pressure should be measured well away 
from pump discharge turbulence and with taps off the side of 
the line to avoid plugging from sediment. Flow should be 
measured in an area where it can accurately be measured; for 
example, for inferential meters — in a location where there is a 
well-developed flow profile. Temperature must be taken in a 
location representative of the majority of the product in the 
line or it will generate errors greater than results achieved 
without the input. 

The design of the instrumentation process piping and the 
instruments should be located to include provision for conve- 
nient testing and calibration of instruments with minimum 
disruption of pipeline operations (see API Manual of Petro- 
leum Measurements Standards for instrumentation). 

5.1 .3 Calibration and Maintenance of CPM 
Instrumentation 

A CPM system that has adequate instrumentation to 
achieve the desired commodity release sensitivity may be 
limited in its effectiveness by instrument calibration drift. A 
system that receives inaccurate data will yield inaccurate 
results. 

Instruments should be calibrated in accordance with manu- 
facturer's recommendations and calibrations should be trace- 
able to National Institute for Standards and Testing. 
Operating experience will provide the basis for determining 
an appropriate test and re-calibration fixed interval. The CPM 
system itself may in some cases be the best indication of the 
necessity to test and re-calibrate a particular instrument a ran- 
dom interval. 

To maximize CPM performance, each pipeline company 
should prepare a test and calibration plan as part of CPM 
operating and maintenance procedure. This plan should rec- 
ognize the importance of the CPM system to the safe opera- 
tion of the pipeline and provide for the priority of CPM 
instrument repair. 

Note: Such a plan could result in instrumentation calibration prac- 
tices that may exceed the requirements of applicable regulations. 

Test and re-calibration events should be documented, and 
such records shall, at a minimum, include the date of the test 
and initials of the person performing the test. Test and re-cali- 
bration records should be retained in accordance with the each 
company's written procedures. The operator should consider 
the storage location for records so that they are protected for 
the life of their required retention. 
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When developing a maintenance history for field instru- 
mentation, consideration should be given to recording "as 
found" and "as left" calibrations in accordance with ISO 
9000 conventions. 

Procedures should be developed to co-ordinate the test and 
re-calibration of field instrumentation with pipeline control- 
lers and CPM system maintenance personnel, since re-cali- 
bration may affect performance of the system. 

5.1.4 Signal Conditioning 

Noise is that part of the signal received that does not repre- 
sent the quantity being measured. Noise exists to some degree 
in all measured data. Noise may reduce the performance of 
the CPM system. 

All practical means should be employed to reduce mechan- 
ical or electrical sources of noise at the instrument. For exam- 
ple, instrument mounts and process piping should be 
designed to minimize resonance. Electrical noise in sensor 
wiring often can be reduced through the use of shielded sig- 
nal cables and proper grounding. 

When attempts to eliminate noise are unsuccessful, signal 
conditioning techniques may be used with some types of 
CPM systems to limit bandwidth and thus attenuate noise. 
API RP 1 1. 49 describes a digital low pass filter that was effec- 
tive in reducing noise and thus improving the leak sensitivity 
under test conditions. These filters may be contra-indicated 
for particular types of CPM systems and that excessive signal 
conditioning may remove desired information. Signal condi- 
tioning techniques also introduce time lags in changing data 
and may reduce the effectiveness of the CPM system. 

5.2 SCADA/COMMUNICATIONS 

The Supervisory Control And Data Acquisition (SCADA) 
system is a computer-based communications system that 
gathers, processes, displays and controls data from field 
instrumentation. This section focuses on the design of the 
data gathering sub-system and its effect on CPM. 

CPM systems will generally use data gathered by the pipe- 
line SCADA system, but some systems may gather data inde- 
pendently. Automated CPM systems may be interfaced bi- 
directionally with the SCADA system to receive pipeline data 
as it becomes available and to provide data back to SCADA 
or return alarm conditions to the SCADA system for alarm 
management utilities. Automatic transfer of the data makes it 
possible for the CPM system to analyze the data at a much 
faster rate. Such automation requires that all necessary data is 
available from the SCADA system or other sources (e.g., 
scheduling computer) particularly when needed. 

The following paragraphs describe several SCADA system 
design factors that can affect the quality and timeliness of the 
data required by a CPM system. 



5.2.1 Communications Media and Error Detection 

Any data communications medium can be used for 
SCADA, but the most common media in the liquid pipeline 
industry are dedicated telephone circuits, fiber optic cable, 
and various forms of terrestrial radio, microwave and satel- 
lite-based systems. These media vary in quality, but all are 
subject to noise and interference causing data corruption. Vir- 
tually all SCADA systems are designed to detect and reject 
corrupted messages. Data Quality Bits (sometime called data 
attributes) are often available in the SCADA system to indi- 
cate lost messages and other information about the data (e.g., 
off scan, alarm inhibited, manually entered, etc.) and should 
be used by the CPM system to identify missing, suspect or 
conditional data. 

5.2.2 Communications Message Structure 

SCADA systems gather data from field instrumentation via 
Data Acquisition Devices (DADs) such as a Remote Terminal 
Unit (RTU), Programmable Logic Controller (PLC), Field 
Data Acquisition Server (FDA), or Flow Computer (FC) 
located at the field site. Each of these devices may be inter- 
changed for specific applications. Data collection designs 
may include any combination of DAD devices interrogating 
other DAD devices for information. Data is then collected in 
one or more computers associated with the pipeline opera- 
tions Control Center. The specifications of the messages 
between the DAD's and the Control Center computers are 
collectively referred to as the communications protocol. 

The protocol is said to be "polled" when the Control Cen- 
ter computer requests data from each field location in turn. 
Typically, when the last field location has been polled, the 
communications polling will return to the first, repeating the 
cycle endlessly. The time interval required to poll all field 
locations and return to the first is referred to as "poll time" or 
"scan time." If the DAD always reports all its data in response 
to a poll, the system is said to be "strictly polled." On some 
SCADA systems, other polling algorithms are also used to 
compensate for media speeds and loading (e.g., interleaved 
scans, demand scans, etc.). 

A DAD may fail to report when polled due to equipment 
failure or noise in the communications channel. This fault 
condition, sometimes called "no reply" is often indicated by 
SCADA system quality bits. 

To improve the update rate on slower communication 
channels and to gain efficiency on the communications chan- 
nel, some protocols permit the field locations to respond with 
only the data that has changed since the previous poll. Such 
protocols are referred to as "Report-by-Exception " Scan time 
in a Report-by-Exception protocol may vary depending on 
system design and operating condition of the pipeline. 

SCADA communications may also be non -polled. "Quies- 
cent" or "Unsolicited" operation refers to DADs that report 
without being polled, either on a time scheduled basis or 
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when field data changes. Refer to 6.2.4 "Analog Deadband" 
for a description of analog data change. The design of quies- 
cent and Report-by-Exception systems may include provision 
for the Control Center computer to poll for all field location 
data. Such a poll is used to verify the validity of the data 
image in the Control Center computer and is called an "Integ- 
rity Scan." 

5.2.3 Communications Timing 

In polled systems the variation in reporting times from one 
field location to another is called "time skew." Designers of 
CPM systems may also consider the impact of time skew in 
the data. 

Quiescent systems that report on data change and Report- 
by-Exception protocols have no defined scan time so the age 
of a particular item of data may be in question. To deal with 
this situation, some SCADA systems generate "Time Tags," 
either in the DADs at the time data changes or in the Control 
Center computer at the time the data is received. Time Tags 
may be used by CPM systems designed to analyze transient 
conditions in the pipeline. 

Some SCADA systems are capable of capturing instanta- 
neous volumetric measurement simultaneously at all loca- 
tions. This feature is usually called "Accumulator Freeze" or 
"Data Snapshot" and effectively permits all volume data to be 
interrogated at one reference time. CPM systems not 
equipped to handle time tags may use this method to elimi- 
nate time skew. 

5.2.4 Analog Deadband 

Measured variables from instrumentation are typically 
called SCADA "Analogs." Report-by-Exception protocols 
and Quiescent systems that report changed data sometimes 
permit "Analog Deadbands." When the Analog Deadband is 
enabled, the value of the Analog must change more than the 
deadband value before the new value is reported. 

Analog Deadbands are generally used to reduce traffic on 
the communications channel. Flicker in the analog signal will 
appear to be a valid change in data in Quiescent and Report- 
by-Exception systems. Deadbands, however, introduce a 
noise level that may be counterproductive for particular CPM 
methodologies that analyze the Flicker for pattern changes. 

When the precision of the SCADA system's analog-to-dig- 
ital conversion hardware exceeds the repeatability of the sen- 
sor, it is appropriate to reduce the precision through the use of 
an analog deadband. Care must be taken not to use an exces- 
sively large analog deadband as this technique effectively 
reduces the precision of the analog value (see 5.1.1). 

5.2.5 The Impact of Data Collection 

CPM systems must be implemented with an understand- 
ing of the underlying communications protocol. It is possi- 



ble to have variation in communications protocol within 
one SCADA system. It is not unusual to find that multiple 
protocols may be used in layers or sequentially to complete 
the transmission of one field message to the SCADA Sys- 
tem. The use of multiple protocols may have no effect on 
update time. 

5.2.6 Data Processing 

Field data received by the SCADA system is generally 
coded in the most compact manner possible to maximize effi- 
ciency on the communications link. Such data is said to be 
"raw." The data processing function in the SCADA system is 
responsible for converting the data to a format suitable for 
display and use by applications such as CPM systems. Recent 
designs may perform this formatting in the DAD. This sec- 
tion describes data processing features that enable or improve 
CPM functionality. 

5.2.6.1 Time Tagging 

Time tags record when a particular data point was last 
updated. Some systems generate the time tags in the DAD, 
but it is more common for the SCADA Control Center com- 
puter to create the time tag at the time the data is either 
acquired or processed. Time tags, preferably originating at 
the DAD, can be used by the CPM system to reduce the effect 
of time skew, especially for accumulator values when a data 
freeze function is not available. 

5.2.6.2 Data Quality 

Data quality information may be stored with processed 
data. Typical data quality values that effect CPM systems 
include: 

a. "Non-updated" or "old data" caused by a DAD that is not 
responsive. 

b. "Off- scan," when an DAD has been taken off-line. 

c. "Manual data," when manually entered data overrides 
interrogated values. 

d. "Range error," when an analog value falls outside speci- 
fied hardware limits. 

e. "Alarm inhibited" when the data is inhibited from alarm- 
ing, even if out of tolerance (typically used during 
maintenance activities). 

Data quality values may be used by the CPM system to 
help recognize and compensate for suspect data. On some 
SCADA systems, data quality bits are also used to reflect the 
results of calculations or operator action (e.g., data is cur- 
rently in a specific type of alarm, pipeline controller has not 
acknowledged an alarm condition, the field point is currently 
part of a control sequence, etc.). 
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5.2.6.3 Analog Processing 

Analog values typically represent measured variables such 
as pressure or flow rate, but can also represent items such as 
tank levels. Raw analog values are scaled into engineering 
units such as pounds per square inch (psi), or barrels per hour 
(bph), or feet by the analog processor. Some variables used in 
particular CPM systems will also require a secondary conver- 
sion to obtain the final desired value (e.g., specific to API 
gravity, level to volume, etc.). The scaled or final analog val- 
ues are usually compared to predefined threshold values to 
detect when the values fall outside the desired range (e.g., 
operating and emergency limits). The rate of change (ROC) is 
a calculated value, which is defined as the change of an engi- 
neering unit value per predefined time period. On Quiescent 
and Report-by-Exception SCADA system, some type of 
smoothing algorithm, independent of the scan time, is usually 
needed to prevent the calculation of unrealistic ROC values 
for particular CPM approaches. 

CPM systems generally rely on the scaled analog values. 

5.2.6.4 Status Processing 

Status data records the state of an item of field equipment. 
Status pairs such as on/off or opened/closed can be stored in 
one binary digit or bit. Some SCADA systems permit the 
configuration of status into 2-bit (4-state) or higher combina- 
tions. 

Changes in equipment state are generally logged to a 
printer or other permanent recording device by the status pro- 
cessor. Such a set of records is usually referred to as an "event 
log." 

CPM systems may need status information to determine 
pipeline configurations or, if transient conditions are the 
result of change in equipment state. The event log may be a 
good source of information when interpreting CPM alarms. 

5.2.6.5 Accumulator Processing 

Accumulator values represent an accumulated total of 
some process quantity since the start of the totalization pro- 
cess. In liquid pipeline SCADA service, accumulators are 
typically used to record volumetric or mass quantities passing 
a given point in the system. The accumulator values may 
either represent "gross," "net," or partially netted values 
depending on the particular type of DAD used (e.g., RTU, 
PLC, flow computer). 

5.2.6.6 Alarm Processing 

Alarms are a special case of events that indicate a transition 
into an unexpected or abnormal state. The return transition to 
the normal state is generally referred to as "return to normal " 
Alarms can either be transitory or continuous in nature. For 



example, a field status bit going into the alarm state or an ana- 
log exceeding a high limit would be examples of continuous 
alarms that have a complementary return to normal state. 
Transitory alarms have no return to normal state and are sim- 
ply an indication that something has occurred (e.g., two 
minute warning prior to a batch arrival, "pig signal" that a 
scraper has passed a station, etc.). 

Alarms can be configured to trigger an audible signal, 
which can be acknowledged or and silenced by the pipeline 
controller. The pipeline controller may also be required to 
acknowledge each alarm as it is displayed. Many SCADA 
systems have special summary lists related to alarms: 

a. Chronological alarm logs/files. 

b. Unacknowledged alarm summaries. 

c. Summaries of points in an unusual state. 

CPM systems may be closely integrated with the SCADA 
system. When CPM alarms and processed data are sent back 
to SCADA, they can be integrated into the standard SCADA 
displays. By maintaining a familiar method of data presenta- 
tion, this approach will facilitate interpretation of the data by 
the pipeline controller. It is also a preferred configuration 
because it allows the pipeline controllers to view and analyze 
CPM data and alarms in conjunction with SCADA activities 
and events. 

5.2.6.7 Data Historian Archiving 

CPM systems may store data values to a historical data- 
base. The SCADA system or other applications such as CPM 
systems may access historical data. 

Playback is a method for capturing field data for recall at a 
later time. The ability to playback SCADA data in a test 
mode can be useful in analysis and tuning of the CPM system 
for training and maintenance 

A combination of historical and playback data may provide 
the ability in some systems to recreate a series of events in a 
CPM system. 

5.3 DATA PRESENTATION 

Interpretation of results from manual CPM systems are 
based on pipeline controller training. Therefore, this section 
is primarily concerned with the presentation of data from an 
automated CPM system. 

Data presentation capabilities vary widely depending on 
the SCADA/CPM system. The contents of this section are 
intended to assist the pipeline company in achieving the best 
possible results in the existing system. 

Effective presentation of Operating and CPM data will 
enable the pipeline controller to more easily identify and 
interpret hydraulic anomalies. 
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5.3.1 Display Ergonomics 

The CPM integrator should carefully consider the aspect of 
display of the CPM system and alarms to the users. Consider- 
ations should include the following: 

a. Displays need to be simple, easy to read, and presented in 
an uncomplicated screen arrangement 

b. If possible, the CPM displays should be have the same for- 
mat and functionality as the SCADA displays so the usage is 
familiar to the pipeline controller but the displays should also 
be clearly differentiated so the pipeline controller will know if 
a SCADA or CPM display is viewed. 

c. When a simulation trainer is used for pipeline controller 
training, the simulation system displays should be the same as 
the on-line Control Center displays so the pipeline controller 
are familiar with the format. 

d. The CRTs should be positioned in a manner to avoid caus- 
ing body and eye strain. 

e. It is important to consult the user during the design of the 
CPM system, so that the pipeline controller is satisfied with 
the layout and design. 

f. Where the Control Center has multiple consoles and pipe- 
lines, the CPM displays should be similar for each pipeline. 

g. The CPM integrator should consider use of industry stan- 
dards, standards of other industries that make use of control 
displays or research that suggests approaches to make control 
displays appropriate for the level of urgency of information 
displayed. 

h. The display should limit the number of colors. 
i. The display should be designed to work well with the par- 
ticular CPM methodology; for example, uppercase letters 
may be more readable on some screens and applications. Also 
the information displayed should be easy to read on the spe- 
cific display equipment that the controller is using. 
j. Screen savers should not be used. 

k. If other tasks are on the same CRT, care should be taken to 
prevent interference with the monitoring of the CPM system. 

5.3.2 Trending 

Trending operating parameters (e.g., flow rate, pressure, 
viscosity, density, over/short and temperature) from the 
SCADA system may help determine what caused a CPM 
alarm. If trending is employed, the trend needs to cover a long 
enough duration to see values prior to when the CPM alarm 
occurred right through to the time when the alarm ends, or the 
current time. Trending analog values can aid in the trouble- 
shooting of alarms in CPM systems because the analog 
devices alone cannot always give all of the information 
needed to make a correct leak declaration. Tabular trends are 
not as easy to analyze as graphical trends but are still effective 
ways to display historical data. 



5.3.3 Alarm Display 

CPM alarms should be consistent with SCADA system 
alarms and should have an appropriate priority. The alarm 
should have an audible tone, and can be varied for different 
categories of alarms. Alarms should have different colors if 
there are different categories of alarms. Acknowledged and 
unacknowledged alarms should be available to the pipeline 
controller without using several steps to get to the alarms. A 
time stamp should be part of the alarm when it is displayed. 

Alarms should be presented as both audible and visual. 
Visual alarms should be presented in such a way as to persist 
for some period of time, especially so as not to be overwritten 
irrevocably by newer alarms. Acknowledged alarms that are 
still in the alarm state should remain readily available to the 
pipeline controller. 

Provision should be made against an alarm being easily 
defeated, or inhibited without just cause. The use of screen 
savers or any other screen blanking is strongly discouraged. 

5.3.4 Integration of CPM and SCADA 

The display of alarms from the CPM system and SCADA 
system should preferably be integrated and put on the same 
alarm display. If the CPM and SCADA systems cannot be 
integrated, the CPM alarms should be displayed so that they 
will be readily noticed. In either case, alarms should be 
logged and retained. 

Non- integrated systems should provide event and alarm 
retention for the CPM. All displays and data should be easily 
accessible by the pipeline controller to aid in operations of the 
CPM system along with the SCADA system. The hardware 
design should provide sufficient resources, either by organi- 
zation of displays or providing sufficient CRTs to display 
needed information for analyzing alarms. 

6 Operation, Maintenance and Testing 

6.1 CPM OPERATIONS 

CPM systems employ an inference engine and an alert 
algorithm that are defined for a given pipeline and its instru- 
ment data, configuration data, and product accounting data. 
The inference engine may use hydraulic calculations or it may 
calculate data to infer the pipeline parameters. The alert algo- 
rithm considers inferred data and/or actual data and will issue 
an alarm if a limit is exceeded, e.g., a mass conservation algo- 
rithm's or a statistical algorithm's defined limits. 

In the context of CPM, an alarm is an automated or manual 
signal or other presentation of data concerning an unusual or 
emergency event on the pipeline to the pipeline controller (via 
a SCADA system pipeline-controller interface, a separate 
interface, or manual tabulation sheets). An alarm could be 
triggered by many causes, including equipment or data fail- 
ure, an unusual operating condition or a commodity release. 
Since there is the potential that the alarm information identi- 
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fies conditions that need attention other than a commodity 
release, the company procedures should require that all CPM 
alarms be evaluated. Simply understanding the cause of the 
alarm condition on a monitored pipeline may not be the end 
of the alarm evaluation. 

6.1.1 Alarm Credibility 

Alarm credibility may be enhanced by occurrence of a cer- 
tain number of non leak alarms so the pipeline controllers 
know that the CPM system is functioning. An excessive num- 
ber of alarms will detract from credibility and may create 
complacency. 

A CPM system design goal is to maximize the system sen- 
sitivity to leaks (or to find all leaks within the system thresh- 
old) and to minimize the occurrence of a leak declaration 
until the alert algorithm within the CPM indicates, with a 
high probability, the presence of an actual commodity 
release. 

6.1 .2 Types of CPM Alarms 

In this publication, CPM alarms are subdivided into three 
classes: DATA FAILURE; UNUSUAL OPERATING CON- 
DITION; and POSSIBLE COMMODITY RELEASE. Ide- 
ally the categorization of the alarm into one of these three 
causes will be made by the CPM system. Many CPM systems 
provide just one type of alarm. In this case, the determination 
of cause will be made by the person who evaluates the alarm 
(the pipeline controller, perhaps jointly with a CPM support 
person) or by a separate piece of software (i.e., an expert sys- 
tem) that provides the cause or probability of cause. Auto- 
matic alarm cause evaluation would be a desirable CPM 
system feature. 

Operational response to a CPM system alarm would nor- 
mally include the following: 

a. Investigation of the cause and initiation of action likely 
following a procedure. 

b. Shutdown of the pipeline based on a pipeline controller 
decision or automatic shutdown of the pipeline in a closed- 
loop control system. 

DATA FAILURE. This class of alarm would occur when 
critical CPM input data is missing or is determined as incor- 
rect. These may also be called system-impaired alarms. Also 
included in this alarm type may be alarms that occur when the 
CPM system fails. An example of missing input data would 
be a communication failure at a metering location. An exam- 
ple of incorrect data would be a pressure instrument that con- 
sistently reports values that have no hydraulic relation to 
other pressure and How data on the pipeline. In this case, the 
instrument may be out of calibration or locked at a fixed 
value. These incidents may be presented as types of data fail- 
ure alarms. These alarms could be automatically generated by 
the SCADA or CPM software or as manual entries in a pipe- 



line controller's shift log. Some CPM systems would indicate 
the effect the data failure has on continued CPM operation. 
The effect of this alarm class could range from minimal or no 
effect to the severe degradation of the CPM commodity 
release detection threshold. In the case of CPM system fail- 
ure, the effect would be total loss of this leak detection type. 
The identified failure of one or a series of measured or calcu- 
lated data points should not trigger a leak declaration. Ideally, 
the internal CPM analysis utility should be able to identify 
data failures and alert the pipeline controller that this problem 
exists. 

These and other CPM alarms need to be presented to the 
pipeline controller in a way that clearly identifies the alarm as 
distinct from a SCADA alarm. 

The procedures that the pipeline controller will follow 
under this situation would be defined by the individual pipe- 
line company for the particular CPM system. 

UNUSUAL OPERATING CONDITION This class of 
alarm may be generated when a data set is outside normal 
operating ranges, fails all tests for a data failure condition, 
and does not meet all tests for a possible commodity release. 
These alarms may also be called diagnostic alarms. This class 
of alarm is intended to provide a second diagnostic condition 
between normal pipeline operation and a possible commodity 
release leak declaration. If the alert algorithm subsection of 
the CPM system cannot determine to a set certainty level that 
a commodity release situation does exist, then some CPM 
systems may declare an unusual operating condition alarm. 
The purpose of this alarm class is to minimize incorrect leak 
declarations. The unusual operating condition alarm would 
notify a pipeline controller of a problem that requires imme- 
diate investigation. For example, this type of alarm would 
occur during slack line or column separation on a pipeline 
that seldom experiences this condition; or during unstable/ 
severe transient hydraulic conditions created by an emer- 
gency shutdown. 

The procedures that the pipeline controller would follow 
under this situation would be defined by the individual pipe- 
line company for the particular CPM system. The unusual 
operation condition alarm may supply data to the pipeline 
controller to aid in the situation analysis. 

These and other CPM alarms need to be presented to the 
pipeline controller in a way that clearly identifies the alarm as 
distinct from a SCADA alarm. 

Continued refinement in this area, which represents a sig- 
nificant technological challenge, may ultimately reduce the 
numbers of this alarm class, allowing the CPM system to 
properly classify more alarms as data failure or possible com- 
modity releases. 

POSSIBLE COMMODITY RELEASE. If the CPM system 
indicates a possible commodity release, an alarm should be 
generated by the CPM system. In most cases, the final deter- 
mination of whether the alarm indicates a commodity release 
will be made by a pipeline controller who will use CPM out- 
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put (and possibly other information sources such as the 
SCADA system), in the case of closed- loop control (which 
may be possible on some pipeline systems), the CPM system 
will automatically initiate action to shut down the pipeline. 

Note: Automatic closed- loop control response to alarm conditions 
that includes automatic valve closure requires a careful study of the 
pipeline hydraulics prior to implementation. Automatic valve clo- 
sures can potentially result in excessive surge pressure in liquid pipe- 
line systems, if automatic valve closures are implemented, then 
ideally the pipeline controller would have the capability to override 
the automatic system for just cause.) 

The operational responses to a possible commodity release 
alarm need to consider these factors: 

a. All CPM alarms have a cause. 

b. CPM alarms will be probabilistic, and need to be assessed 
in light of the current sensitivity threshold. 

c. Prior instances of alarm causes can be a useful guide in 
alarm evaluation, but every alarm should be evaluated indi- 
vidually and assumptions of previous causes not be readily 
made. 

6.2 SYSTEM TESTING 

Testing of CPM systems evaluates actual system perfor- 
mance and provides a baseline of achieved performance. The 
CPM baseline may be established by testing, operating expe- 
rience, off-line modelling, or an API RP 1 149, API RP 1 155 
or other theoretical analysis of the CPM/pipeline fit. This sec- 
tion outlines testing methods and intervals. 

The primary purpose of testing is to determine that the 
CPM will alarm if a commodity release occurs. The purpose 
of tests could also to be make sure that data failure alarms and 
unusual operating condition alarms function as expected. The 
text that follows will not discuss CPM testing for other than 
commodity release alarms. The testing may also continue 
after the occurrence of the alarm to see also the transition 
from alarm state back to normal state. 

Prior to testing, careful planning should be considered as to 
the reasons for the test and methods that will be employed 
and the process and procedures that will be followed. The test 
should be well managed to make sure it achieves the desired 
results. 

Consideration should be given to the potential for a 
reduced level of pipeline monitoring during a CPM system 
test. The pipeline controllers should be alert to the possibility 
of an actual commodity release that could occur simulta- 
neously with the CPM system test and that an actual com- 
modity release may be disguised or misdiagnosed during the 
test interval. 

6.2.1 Testing Methods 

CPM systems should be tested to alarm state with actual or 
simulated commodity removal. The test method and testing 



parameters should be representative of line operating condi- 
tions. 

Possible methods of testing include, but are not limited to 
the following: 

a. Removal of test quantities of commodity from the line. 

b. Editing of CPM configuration parameters to simulate 
commodity loss (software simulations) or a desired hydraulic 
condition. 

c. Altering an instrument output, e.g., a meter factor, to simu- 
late a volume imbalance, or a pressure output to simulate a 
hydraulic anomaly that represents a leak. 

d. Other means that are capable of testing the performance of 
the CPM system. 

The method used should be specific to the particular CPM 
application and pipeline system. CPM tests may be 
"announced" or "unannounced." An announced test begins 
with the awareness of the pipeline controller and tests only 
the CPM system. An unannounced test begins without the 
knowledge of the pipeline controller and tests the CPM sys- 
tem as well as the response of the pipeline controller. Gener- 
ally, unannounced tests are used only if the performance of 
the CPM system has been established by previous successful 
announced tests. When a series of tests are conducted, only 
the first test can be unannounced. 

The location of the test may vary from one test to the next 
so the CPM system experiences leak tests at various loca- 
tions. This may increase the confidence in the capabilities of 
the CPM system. Also, the test may be performed at more 
than one withdrawal or simulated withdrawal rate so the time 
and leak rate response of the CPM can be evaluated over a 
range of possible leaks. 

6.2.2 Initial Tests During CPM Commissioning 

A new CPM system must be tested to verify that it has 
achieved the design or expected performance and to establish 
a baseline of performance. The reasons for testing a new 
CPM application are different than for retesting (which is out- 
lined below). Throughout the installation and commissioning 
procedure, there may be a number and variety of tests. These 
would test the ability of the CPM system to function under 
varying operating conditions that are indicative of line opera- 
tions. Initial tests may use simulated commodity releases. 
Consideration may be given to testing by actual removal of 
commodity from the pipeline for the final system test, 
because the final test prior to acceptance will establish the 
baseline. 

Subsequent CPM implementations on similar pipelines 
that employ the same CPM methodology may use different 
initial test methods and may take advantage of CPM work 
and testing on other pipelines. 

Initial CPM tests may be rigorous and may be planned and 
executed using good engineering and technical judgement on 
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issues such as test methods employed, commodity loss rates, 
and situations to be simulated. 

6.2.3 Retesting 

CPM retesting of applications will be necessary on a peri- 
odic basis to meet regulations, to confirm the continued effec- 
tiveness of the CPM, or to re-establish CPM performance 
after significant changes have been made to an existing CPM 
application or to the pipeline configuration. Retesting will be 
documented in test records. 

CPM applications should be tested on a 5-year interval (or 
more frequently if significant changes have been made to the 
CPM or the pipeline segment or if there is a change in regula- 
tions that require retesting) to confirm the CPM's continued 
effectiveness. It may be unnecessary to test each pipeline sys- 
tem that uses the same CPM application, but consideration 
may be given to rotation of the tested pipeline and to varying 
the location of the test from one test to the next. The re test 
may use the same method employed in the initial tests or may 
use another test method. 

Operational use of a CPM system, e.g., successful detec- 
tion of a commodity release, may be an acceptable substitute 
for periodic retesting if it demonstrates continued effective- 
ness of the CPM. A successful identification of an actual com- 
modity release, by an in-production CPM, shall be considered 
as sufficient for resetting of the 5 -year retesting interval. 

Subsequent tests may not be as rigorous as the initial tests. 
If no changes have been made to the pipeline of the CPM dur- 
ing the retest interval, the re test will be a confirmation test 
only. 

6.2.4 Maintenance Testing 

Maintenance testing is a type of CPM retesting but for a 
different purpose than outlined above. Maintenance testing 
may be performed on a much more frequent basis than retest- 
ing. There could be many reasons to perform maintenance 
testing on an operating CPM system. For example, through- 
out the life of the CPM system, it may be necessary to recon- 
figure and retest the CPM software when the pipeline system, 
SCADA system, CPM software or configuration changes; 
instrumentation changes; or any other changes occur to a 
degree that there may be a concern that the change will affect 
the CPM system performance. Among those may be testing 
following minor tuning changes, installation of a new soft- 
ware release, event re-run testing to examine CPM response 
to an unusual operating condition. The decision to perform 
maintenance testing will be based on individual analysis of 
possible effect on performance and on a line-by-line basis. 
Maintenance testing may be included as a part of change 
management. 

Maintenance testing may employ an actual commodity 
release data- set, a data- set from a leak test; or a test simula- 



tion. The persons responsible for the CPM will determine that 
method is best suited to maintenance test the CPM system. 

The results of maintenance testing may not be recorded in 
test records. However, when the maintenance test is docu- 
mented in accordance with 6.2.6, such maintenance tests may 
be considered a retest and will set the start of a new testing 
interval. 

6.2.5 CPM Systems Self Testing 

Some CPM systems may be capable of running self diag- 
nostics on a scheduled basis. Such diagnostics may monitor 
the health of the CPM system and may create CPM alarms. 
This may be a desirable system feature if the disruptive effect 
of these alarms on the pipeline controllers can be minimized. 

CPM systems self tests do not meet the criteria for retest- 
ing or maintenance testing. 

6.2.6 Test Records 

Records detailing the reasons for the tests, the test parame- 
ters and methodology, and the test results should be recorded 
and retained for initial tests and for retests. These details of at 
least two previous tests should be retained. Details of any 
actual commodity release, if that event is considered as a 
retest, should be retained at least as a part of the two previous 
tests. 

The pipeline company or operator policy will dictate the 
requirements for documentation of tests. Considerations for 
what information to include in the test records include: 

a. Date, time and duration of the test. 

b. Technical reasons for the test that documents the reasons 
the test is to be performed and why the methodology and par- 
ticular parameters have been chosen. 

c. Method, location and description of the commodity with- 
drawal when used. 

d. Operating conditions at the time of the test. 

e. Details of any alarms generated during the test. 

f. Analysis of the performance of the CPM system and, for 
unannounced tests, the effectiveness of the response by oper- 
ating personnel. 

g. Documentation of corrective measures taken or mitigated 
as a result of the test. 

6.3 OPERATING ISSUES 

For an operating CPM system, the following issues need to 
be considered: 

6.3.1 Security 

Provisions should be made to limit operations and mainte- 
nance access for changes to the SCADA/CPM system, logic 
solver (i.e., PLC, RTU, etc.), alarm limits, and to deactivation 
of sensors. The access protection may be in the form of pass- 



Computational Pipeline Monitoring for Liquid Pipelines 



13 



words, locked cabinets, "read only" or "write protected" data 
and administrative procedures. Access protection may have 
varying levels of accessibility for different users, e.g., systems 
designers, technicians, pipeline controllers. 

Provisions should be made against any alarm, parameter, 
and/or sensor being inhibited without just cause. 

Access control and security may be provided by a combi- 
nation of application logic and passwords for any CPM user 
interface device, parameter, alarm inhibit, and or limit which 
could interfere with or degrade the performance of the CPM 
function. 

System changes can be made through several ways. These 
changes should be coordinated or otherwise managed, for 
example, by segregating the degree of changes by multiple 
levels of accessibility. Any changes should be audited and the 
changes should not go on-line or active until validation is 
complete. Any parameter or function that requires validation 
after the change should not be immediately incorporated in 
the on-line production system; instead, it should be accessible 
and tested only in an off-line mode, if possible. 

An audit trail should be maintained to include date, time, 
parameter, original setting, new setting, and person perform- 
ing the change. 

All alarms and operator initiated commands and events 
which are part of data retention, may be stored in hard copy 
or "read only" format. All read only files should be protected 
from loss and unauthorized tampering. 

The operating company should develop and implement a 
revision and release policy for software and firmware used in 
a CPM system. 

6.3.2 Parameter Changes 

Consideration may be given to allow the pipeline controller 
to make changes to parameters that are important in day- to- 
day or shift specific operation. The system design may 
include provisions to allow the controller to modify and 
adjust parameters within fixed boundaries. Changes by the 
pipeline controller that affect the long-term operation of the 
CPM system should not be allowed. 

The ability to make changes in the CPM system bound- 
aries should only be accessible to authorized personnel and 
under the control of appropriate written procedures. Such 
changes should be recorded in either the an automatic log in 
the shift log. 

6.3.3 Pipeline System Maintenance Activities 

The pipeline controller should be informed or have an indi- 
cation whenever a CPM system sensor is inhibited and or dis- 
abled. These indicators show the system to operate in a 
degraded mode. This may include the sensor's calibration 
problems, communications problems, and software failures. 
This indication, when identified, could be provided by the 



SCADA system or other data gathering methodology if not 
integral to the CPM system. 

Provisions should be made to minimize the effect of main- 
tenance on the capabilities performance integrity of the CPM 
during periods of hardware, software and field equipment 
maintenance and system upgrades. 

System maintenance should be performed under the con- 
trol of maintenance procedures that address the effect of field 
and system maintenance on CPM performance. The proce- 
dure may also address the communications requirements 
between maintenance personnel and the pipeline controller. 

6.4 CPM SYSTEM DATA RETENTION 

The retention of data and reports from a CPM system may 
be governed by several factors, including the requirements of 
regulations, legal requirements, engineering and operations 
requirements and the pipeline controller training require- 
ments. Careful consideration of what should be retained over 
and above that required by regulations, is recommended. The 
considerations should also include what sorts of data and 
information may be useful or helpful in the future; for exam- 
ple, a data- set from a leak or leak test that can be used to ver- 
ify CPM performance after changes have been made to the 
system. 

In any case, all occurrences of a leak declaration should be 
historically documented as to cause, assessment and pipeline 
controller response. 

6.5 PIPELINE CONTROLLER TRAINING & 
RETRAINING 

The users of the CPM system (i.e., the pipeline controllers) 
and any CPM support staff require appropriate CPM training. 
CPM alarms may be the most complex type of alarm experi- 
enced by the pipeline controller. Specific training and refer- 
ence material is necessary to prepare the pipeline controller to 
adequately recognize and respond to these alarms. This 
requires both a knowledgeable perspective on the alarms 
themselves as well as the nature of the alarms. The American 
Petroleum Institute has created a Recommended Practice for 
Controller Training that considers many important related 
training issues outside the scope of this publication. 

The training plans may include periodic reviews of pipe- 
line controller training material to make sure it is up-to-date, 
retraining of the controllers and possibly knowledge testing. 
Retraining may be aided by review of known cases where the 
unusual operating condition alarms and possible commodity 
release alarms have been generated. Documentation of these 
alarms will assist with this activity. 

The following technical areas may be considered (only as 
relate they to the CPM system): 

Hydraulics. A pipeline controller must be trained in the 
basic concepts of pipeline steady state hydraulics as they 
relate to the CPM system. The gradual change of the line 
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hydraulics due to movement of different fluid batches or tem- 
perature change, for example, may be part of a controller's 
education. 

A pipeline controller must be trained to recognize the 
effects of pump start-ups/shutdowns, a valve operation switch, 
and other everyday activities that case transient conditions. 
Any of these will cause a system flow or pressure transient to 
appear and will, therefore, potentially be a problem for the 
CPM alarm notification system. Everyday pipeline transients 
may cause upsets in a CPM system that cannot accommodate 
transients. The upsets may cause operating alarms that are 
well within the realm of normal system behavior. 

Alarming/Performance. The pipeline controller should be 
able to recognize and react to all types of CPM-related 
SCADA alarms, such as "Communication Outage." Some 
SCADA alarms affect CPM system performance. 

The pipeline controller should be able to qualitatively iden- 
tify the effect of an instrument failure on the CPM system. 
The pipeline controller should be trained to link the alarm 
event with the concept that the CPM system would be 
impaired. 

Validating CPM Alarms. An evaluation of the CPM system 
and operating conditions is necessary for validating or 
explaining the cause of a CPM alarm. The pipeline controller 
should be trained to recognize and react to unusual operating 
conditions and to take appropriate action. The training may 
be directed towards following procedures or calling on and 
working with external resources for alarm evaluation. 

Inventory Control (Online). A pipeline controller should be 
trained to recognize CPM hydraulic changes due to varying 
line pack. A fundamental element of the spectrum of inven- 
tory control is the calculation of mass, or the comparison of 
net barrels in versus net barrels out. This training would 
include the ability to recognize the packing behavior of the 
pipeline(s) that they operate. 

A pipeline controller should be knowledgeable about sec- 
tions of the pipeline that are susceptible to intermittent "slack 
line flow." The controller should be knowledgeable about 
how that condition affects the CPM performance. 

Trending. A pipeline controller should be able to recognize 
that trending and analysis of certain pipeline variables pro- 
vides a simple form of CPM system. Trending data can be 
presented graphically or may be presented as a tabular display 
of historical data A graphical output may provide the best 
visual history of CPM parameters. The controller should be 
able to cross correlation CPM output with SCADA output 
wherever possible to have independent confirming data for 
CPM alarm evaluation. 

CPM System Operation. The pipeline controller must be 
trained to understand the CPM system, and the concepts of its 
operation. A portion of pipeline controller training may 
include periodic review of the use of the CPM system in a 
training environment, and the training may cover all the vari- 
ous CPM systems in use within the Control Center and 



unique aspects of each application as they apply to individual 
pipeline segments. 

The pipeline controller must be trained to interpret alarms 
correctly and in a timely manner or work with internal or 
external resources to evaluate the alarm. The CPM system 
should be implemented so the alarms are readily recognizable. 

Data Presentation. A pipeline controller must be trained in 
the recognition of the CPM notification or alarm and may be 
trained to research the cause of the alarm (data failure, 
unusual operating condition or possible commodity release), 
or in methods of correlation of the alarm to independent data 
so the controller will pursue the appropriate response. The 
presentation of CPM alarm data is a crucial component, such 
as the trend of the probability of a leak, or the description of 
the location for which the leak declaration has occurred. 

Abnormal Functions. The pipeline controller must be 
trained to react to the abnormal function of a CPM system in 
the same way as being trained to react to the abnormal func- 
tion of the SCADA system. The loss of either must elicit cer- 
tain predefined actions intended to preserve pipeline integrity. 
Targeted response actions should be thoroughly analyzed and 
scripted for prompt, efficient action. 

Other Leak Detection Methods. The pipeline controller 
should be trained in how to employ the results of other meth- 
ods of detecting leaks such as third-party reports so that a 
CPM system is not considered to be the only means of detect- 
ing leaks. The controller should know what procedures to fol- 
low for these other methods. 

6.6 CPM DOCUMENTATION 

Each CPM system employed on a pipeline segment should 
be fully described and the documentation should be readily 
available for reference by the users and by those employees 
responsible for the maintenance and support of the CPM sys- 
tem. It is recommended that the following information be 
available: 

a. General Information (this information is usually available 
as a part of normal Control Center information). 

b. A system map, profile and detailed physical description 
for each pipeline segment. 

c. A summary of the characteristics of each product 
transported. 

CPM Specific Information: 

a. A tabulation of the inputs used in the CPM procedure for 
each pipeline segment. 

b. A general description of the CPM outlining its principles 
of operation. 

c. A list of special considerations or step-by-step procedures 
to be used in evaluating CPM results and for requesting assis- 
tance with alarm evaluation, e.g., on-call support phone 
numbers where this systems is implemented. 
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d. Details of the expected performance of the leak detection e. CPM pipeline controller training manuals or information. 

system under normal and line upset conditions; and the f. CPM alarm thresholds for the various applications, 

effects of system degradation on the leak detection results. 
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A.1 accumulator data: A SCADA data value that repre- 
sents an accumulated quantity, usually volume in liquid pipe- 
line service. 

A.2 accumulator freeze: A feature of some SCADA 
protocols that allow all volumetric data to be captured at vir- 
tually the same time. It may be used to eliminate time skew in 
volumetric data analysis. 

A.3 alarm: A notification to the pipeline controller that an 
hydraulic anomaly has been detected that is outside pre-set 
limits. The event requires a response from the pipeline con- 
troller. Alarms are usually displayed in a prominent manner 
with an audible signal to the pipeline controller. This may be 
declared visually and/or audibly. 

A.4 alarm acknowledgement: An action by the pipe- 
line controller, signifying that the alarm event is recognized. 

A.5 alert algorithm: A part of a CPM system that evalu- 
ates the inferred measurements (calculated or accumulated in 
the inference engine), compares against the thresholds and 
issues a CPM alarm. 

A.6 analog data: A SCADA data value that represents 
some measured quantity, for example, temperature or pressure. 

A.7 analog deadband: A SCADA parameter that 
defines the increment of change in an analog value that is sig- 
nificant. A monitored analogue value change that is less than 
the deadband will be ignored. 

A.8 commodity release: A loss of fluid from the pipe- 
line. Within the context of this publication, a commodity 
release when referenced to leak rate, must be above the leak 
threshold of the particular CPM system and pipeline. Other 
industry terms are product release or pipeline leak. 

A.9 communication failure: An interrupt in SCADA 
messaging usually between the Control Center computer 
RTU, PLC or Flow Computer. It may be a loss of communi- 
cation either by total outage of the communication link or by 
failure of the remote site to respond to data required by the 
Control Center computer. 

A.10 communications messaging protocol: The 

specific format of the data communicated amongst the Con- 
trol Center computers and RTUs PLCs and Flow Computers 
in a SCADA system. 

A.11 computational pipeline monitoring or CPM: 

An algorithmic monitoring tool that alerts the pipeline con- 
troller to respond to a detectable pipeline hydraulic anomaly 
(perhaps both while the pipeline is operating or shut-in), 
which may be indicative of a commodity release. 



A.1 2 data acquisition device: A field device used to 
acquire data from field sensors and transmit the data to the 
Control Center computers. Some Data Acquisition Devices 
also contain intelligence to perform local field logic and oper- 
ations. 

A.1 3 data archiving: A SCADA system feature that 
records data in an historical database under some pre-defined 
data management process. 

A.1 4 data quality: A SCADA system feature that creates 
status bits that are attached to the message to reflect the valid- 
ity of process data. 

A.15 drag reduction agent: An additive used on liquid 
pipelines to reduce the amount of friction loss. Also referred 
to as "DRA." 

A.1 6 event log: A SCADA system feature that creates a 
permanent record of changes to the pipeline and the system's 
state in chronological order. 

A.1 7 excursion alarm: An alarm that indicates that the 
CPM system has detected a hydraulic anomaly that is outside 
the defined limits. Typically, a SCADA system-generated 
event that alerts the pipeline controller to an analog data value 
that has been detected outside a pre-set range. Also called a 
threshold or range alarm. 

A.1 8 false alarm: A commonly misused term in the con- 
text of CPM systems to refer to alarms that are not caused by 
an actual commodity release or other emergency or unusual 
operating condition. 

A.1 9 filter: A device or algorithm to remove unwanted 
components from a process signal. Also called signal condi- 
tioning. 

A.20 fluid properties: The characteristics of the fluid 
that describe its hydraulic behavior, including: density, vis- 
cosity, compressibility (or bulk modulus); coefficient of 
expansion; thermal capacity. Many CPM techniques also 
need to consider the effects of Pipeline Drag Reducers on 
fluid properties. 

A.21 historical data: Data that has been retained for later 
retrieval. Typically maintained by a SCADA system's data 
archival subsystem. 

A.22 hydraulic anomaly: An unusual condition on the 
pipeline or abnormal operating condition that is explainable 
through the systems hydraulics. 

A.23 inference engine: A part of the CPM system that 
accumulates data, performs calculation (e.g., line hydraulics) 
and provides outputs to the alert algorithm. 
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A.24 Integrity Scan: A special message in a "Report-by- 
Exception" SCADA communication protocol that verifies that 
the Control Center computer has an accurate picture of field 
data. Since only changed data is reported form the field in 
such a protocol, lost messages could result in inaccurate data 
in the Control Center Computer. Some systems require an "all 
data" or other health check response on a scheduled basis to 
achieve data integrity in "Report- by-Exception" systems. 

A.25 leak declaration: The declaration that is made if a 
pipeline controller has reasons to suspect that a commodity 
release is occurring on the pipeline. 

A.26 manual data override: When manual entries are 
input in lieu of actual field data values. 

A.27 manual system: A CPM system that is based on 
non-software algorithmic calculations. 

A.28 mass balance: A mathematical process that con- 
siders the fluid injected, delivered and the change in inventory 
of the pipeline so all of the fluid is accounted. 

A.29 material balance: A mathematical procedure based 
on the laws of conservation of mass and fluid mechanics and 
is used to determine if a commodity release has occurred on a 
pipeline system. May also be called mass balance. 

A.30 Newtonian (non-Newtonian) fluids: Newtonian 
fluids have predictable viscosity characteristics. Viscosity can 
be calculated for various temperatures and pressures. Non- 
Newtonian fluids have unpredictable viscosity characteristics 
that cannot be easily calculated. Most fluids that exhibit non 
Newtonian characteristics are Newtonian above some partic- 
ular temperature. 

A.31 no reply: A state in SCADA communications in 
which the RTU or PLC does not make a valid response to the 
Control Center computer's request for process data. "No 
Replies" are expected some percentage of the time depending 
on the design of the communication channel. 

A.32 noise: An unwanted component in a process signal. 
Noise may be reduced by filtering. 

A. 33 over/short: A manual, computer-based or automatic 
calculation of volumes of fluid injected from which the vol- 
umes delivered are subtracted. Volumes may be corrected for 
temperature. The calculation indicates if the injections equal 
the deliveries. Over/short may be positive or negative. Also 
may be called loss/gain. 

A.34 pipeline controller: A person who is responsible 
for the monitoring and direct control of a pipeline. This is the 
accepted industry term for this position (as outlined in API 
Publ II 18). Other industry terms used are operator, opera- 
tions coordinator or dispatcher. 



A.35 pipeline rupture: In the context of Computational 
Pipeline Monitoring (CPM), a rupture is a pipeline leak that 
releases a large quantity of the pipe's contents. A rupture will 
occur when there is a significant breach of the pipe wall or 
major loss of containment of the product within the pipe. It 
may also be characterized by registering a differential far 
larger than system noise in some measured/trended values on 
the SCADA system, and the rupture will cause an immediate 
impairment to the operation of the pipeline. The size of a 
pipeline rupture is difficult to define as indicated in the expla- 
nation that is provided in Appendix B of this publication. 

A.36 PLC (programmable logic controller): An intel- 
ligent field device that collects various instrument data, pro- 
vides interim sequence control, and packages station 
information for transmission to a SCADA system. 

A.37 polling: One method by which the Control Center 
computer can acquire field data by issuing sequential requests 
to field Data Acquisition Devices (e.g., RTUs, PLCs, and flow 
computers). These requests, called polls typically proceed in a 
continuous cyclic manner across many field locations. 

A.38 protocol: The specifications of the message struc- 
ture between RTU or PLC and Control Center computer are 
collectively referred to as the communications protocol. 

A.39 quiescent protocol: One type of SCADA commu- 
nication protocol in which the RTUs and PLCs initiate mes- 
sages containing process data for transmission to the Control 
Center computer. Such messages can be triggered by a 
change in process data or created on a time-driven basis. Also 
called unsolicited protocol. 

A.40 rate Of change: A calculated value that reflects the 
change in an analog data value per unit time. 

A.41 reliability: A measure of the ability of a CPM sys- 
tem to render accurate decisions about the possible existence 
of a commodity release on a pipeline, while operating within 
an envelope established by the CPM system design. This term 
is fully defined and discussed in API Publ 1 1.55. 

A.42 remote terminal unit or RTU: A SCADA system 
component, typically installed at a field site, that gathers pro- 
cess data from sensors for transmission to the Control Center 
computer. The RTU or PLC also accepts control command 
messages from the Control Center computer and transforms 
those commands to electrical output signals. Also a generic 
term that refers to any device that can respond to requests for 
information from a Control Center computer or PLC or can 
send unsolicited information in a non-polled environment. 

A.43 report-by-exception: A feature of some SCADA 
communication protocols that intends to improve communi- 
cation efficiency by reporting only the data that has changed 
since the previous poll. 
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A. 44 return to normal: The transition from alarm to nor- 
mal state that signifies that an alarm condition has ended. 

A. 45 SCADA: An acronym for Supervisory Control and 
Data Acquisition, the technology that makes it possible to 
remotely monitor and control pipeline facilities. 

A.46 scan time: The time interval between two consecu- 
tive polls to Data Acquisition Devices on a SCADA commu- 
nication channel. Also called Polling Time. 

A.47 segments: A segment typically refers to a shorter 
section of pipeline. A segment is bounded by defined by 
instrumentation (e.g., meter) or other physical features of the 
pipeline (e.g., valves). 

A.48 sensitivity: A composite measure of the size of a 
leak that a CPM system is capable of detecting and the time 
required for the system to issue an alarm in the event that a 
commodity release of that size should occur. This term is 
fully defined and discussed in API Publ 1 1 .55. 

A. 49 shut-in: A pipeline that is shut-in is not operating 
(fluid is not entering or leaving the pipe) at the time it is shut- 
in. Valves may be closed to prevent fluid flow when the pipe- 
line is shut-in. 

A.50 single phase: A fluid state, either liquid or gaseous, 
based upon commodity, vapor pressure, pipeline pressure and 
temperature. 

A.51 slack line: The condition where a pipeline segment 
is not entirely filled with liquid or is partly void. May also be 
called column separation. 

A.52 status data: A SCADA data value that represents 
the operational state of an item of field equipment. 



A.53 steady state conditions: The pipeline hydraulic 
condition that exists when all the pipeline operating parame- 
ters remain nearly constant over a period of time. 

A.54 system: A system refers to a entire entity such as a 
complete pipeline. Segments (see above) are subset of a 
system. 

A.55 threshold: A threshold is an upper or lower estab- 
lished value for a particular parameter (e.g., a defined pres- 
sure value). When a threshold is exceeded, the actual 
parameter value is outside the range of the define value (usu- 
ally above or below the threshold). A threshold may be fixed 
(i.e., its value does not change) or dynamic (where the value 
changes in time). 

A. 56 time Skew: The variation in reporting times from 
one Data Acquisition Devices to another in a polled SCADA 
communications protocol. In a polled system, the variation in 
reporting time from one Data Acquisition Devices to another. 

A.57 time tag: A SCADA system feature that records the 
time that a measurement or event occurs along with the data. 

A.58 time tag error: The difference between the time the 
actual measurement was made and the time tag associated 
with the measurement. 

A.59 transient operating conditions: The pipeline 
hydraulic condition that exists when any pipeline parameter is 
changing in time. 

A.60 unusual operation condition: A pipeline operat- 
ing condition which is not displayed during the normal opera- 
tion of the pipeline. For example, a slack line condition or 
column separation that occurs infrequently on the pipeline. 



APPENDIX B— DISCUSSION OF PIPELINE RUPTURE DEFINITION 



The size of a commodity release or leak and rupture is 
defined in this appendix in the context of how it relates to 
CPM Figure B-l shows a representation of commodity 
release sizes. The relationship of rupture size to other leak 
sizes is important because regulations may call for a CPM 
that is able to detect pipeline "ruptures." 

A rupture cannot be considered to be at a fixed value of 
commodity release relative to the line flow rate or volume of 
the pipeline. The following factors characterize a rupture: 

The volume of product loss that occurs in a rupture will be 
different for each individual pipeline. The volume released in 
a rupture on a small pipeline will be much less than on a large 
pipeline. 

Operating conditions of the pipeline (steady state or tran- 
sient) will influence the minimum size of commodity release 
above which a leak can be called a rupture. CPM detection 
limits are not fixed. API Publ 1 149, for example, provides 
methods to calculate theoretical detection limits while the 
pipeline is in steady state operation and when hydraulic con- 
ditions are transient. During transients the detectable limit is 
significantly higher. 

The time interval may be considered in defining a pipeline 
rupture. A specific volume of a commodity release that 
escapes over a short period of time could be classified as a 
rupture whereas the same volume over a far longer period of 
time may not be designated as a rupture. 



If a requirement exists to recognize a commodity release 
size above which a rupture is defined, it may be done by the 
pipeline operator. In defining a rupture on an individual pipe- 
line, the pipeline operating company may need to consider 
the following: 

a. if slack line flow exists at the time of the commodity 
release. 

b. The line pressure at the rupture site. 

c. The operating state of the pipeline (steady state, or tran- 
sient and the severity of the transient). 

d. The CPM methodology which is used to detect the com- 
modity release. Some methods are optimized to detect small 
leaks over a longer period of time. 

e. The SCADA scan time. Long scans time will not provide 
field data as quickly. 

f. The flow rate of the line at the time of commodity release 
occurrence. At a lower than normal rate the CPM system may 
be less sensitive. 

g. The temperature gradient may affect the calculation of 
pipe inventory. 

h. The CPM pipeline segmentation. Longer sections of CPM 

monitoring will have a greater uncertainty to overcome 

before a leak declaration can be made. 

i. The pipe volume and length will affect the detectable 

limit. 




Rupture lower threshold by definition 



Lower practical: Commodity release limit 
(may use API RP 1155 to establish) 



Theoretical lower limit of CPM detection 

(may be established by API RP 1149 or other methods) 



Figure B-1 — Graphic of Leak/Rupture Definition 
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APPENDIX C— DESCRIPTION OF TYPES OF INTERNAL BASED CPM SYSTEMS 



A CPM system is comprised of two parts which can be 
called an Inference Engine and an Alert Algorithm. Figure 
C-l shows the two parts, and these two parts are defined 
above. 

The inference engine accepts data from instruments on the 
pipeline. For CPM systems the most common being: flow 
meters, pressure sensors, temperature sensors, densitometers, 
and status's (valves, pumps). The data may be used in calcu- 
lations to produce new values, for example flow may be cor- 
rected to standard conditions; the calculations may use 
hydraulic formula to calculate fluid flow; or pressure may be 
averaged. The values are then passed to the alert algorithm. 

The alert algorithm accepts values from the inference 
engine and/or data for field instruments and compares the val- 
ues to thresholds. If the values exceed the threshold the algo- 
rithm determines if an alarm and what type of alarm should 
be generated. 

C.1 Line Balance (LB) 

This meter-based method determines the measurement 
imbalance between the incoming (receipt) and outgoing 
(delivery) volumes. The imbalance is compared against a pre- 
defined alarm threshold for a select time interval (time win- 
dow). There is no compensation for the change in pipeline 
inventory due to pressure, temperature or composition. 
Imbalance calculations are typically performed from the 
receipt and delivery meters, but less timely and less accurate 
volumes can be determined from tank gauging. Line balanc- 
ing can be accomplished manually because of its simplicity. 

C.2 Volume Balance (VB) 

This method is an enhanced line balance technique with 
limited compensation for changes in pipeline inventory due to 
temperature and/or pressure. Pipeline inventory correction is 
accomplished by taking into account the volume increase or 
decrease in the pipeline inventory due to changes in the sys- 
tem's average pressure and/or temperature. It is difficult to 
manually compensate for changes in pipeline inventory 
because of the complexity of the imbalance computation. 
There is usually no correction for the varying inventory den- 
sity. A representative bulk modulus is used for line pack cal- 
culation. 

C.3 Modified Volume Balance (MVB) 

This meter-based method is an enhanced volume balance 
technique. Line pack correction is accomplished by taking 
into account the volume change in the pipeline inventory uti- 
lizing a dynamic bulk modulus. This modulus is derived from 
the bulk moduli of the various commodities as a function of 
their percentage of line fill volume. 



C.4 Compensated Mass Balance (CMB) 

As a further enhancement to the MVB method, this volume 
balance technique models pipeline conditions between mea- 
surement points to more accurately determine pressure and 
temperature profiles as input for the line pack calculation. 
The pipeline is sub-divided into a pre-defined number of seg- 
ments based on available instrumentation, elevation charac- 
teristics, and the desired level of sensitivity. In addition, 
inventory locations are determined through batch/DRA/ 
hydraulic anomaly tracking. Volume imbalance is typically 
monitored over a number of time periods (e.g., 15 minutes to 
24 hours, also weekly and monthly) to detect commodity 
releases of different sizes. 

C-5 Real Time Transient Model (RTTM) 

The fundamental difference that a RTTM provides over the 
CMB method is that it compares the model directly against 
measured data i.e., primarily pressure and flow) rather than 
use the calculated values as inputs to volume balance. Exten- 
sive configuration of physical pipeline parameters (length, 
diameter, thickness, pipe composition, route topology, inter- 
nal roughness, pumps, valves, equipment location, etc.) com- 
modity characteristics (accurate bulk modulus value, 
viscosity, etc., and local station logic (e.g., pressure/flow con- 
trollers) are required to design a pipeline specific RTTM. The 
application software generates a real-time transient hydraulic 
model by this configuration with field inputs from meters, 
pressures, temperatures, densities at strategic receipt and 
delivery locations, referred to as software boundary condi- 
tions. Fluid dynamic characteristic values will be modeled 
throughout the pipeline, even during system transients. The 
RTTM software compares the measured data for a segment of 
pipeline with its corresponding modeled conditions. 

C.6 Pressure/Flow Monitoring 

Pressure/flow values that exceed a predetermined alarm 
threshold are classified as excursion alarms. Initially, excur- 
sion thresholds are set out of range of the system operating 
fluctuations. After the system has reached a steady -state con- 
dition, it may be appropriate to set thresholds close to operat- 
ing values for early hydraulic anomaly recognition. 

Pressure/flow trending is the representation of current and 
recent historical pressure and/or flow rate. These trends may 
be represented in a tabular or graphical format on the Control 
Center monitor to enable a pipeline controller to be cognizant 
of these parameter fluctuations. This method can be used to 
display operating changes from which a pipeline controller 
can infer commodity releases. 

Rate-of-change (ROC) calculates the variation in a process 
variable over a defined time interval. The rate at which line 
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pressure and/or flow changes over to time are the two most 
common forms of ROC for pipeline operation. The intent of 
this approach is to identify rates of change in pressure and/or 
flow aside from normal operating conditions, thereby infer- 
ring a moderate to large commodity release if operating 
hydraulic anomalies cannot be explained. 

In general, there are four types of pressure/flow monitoring 
techniques used on liquid pipelines to indicated unusual oper- 
ating conditions and potential leak conditions: 

1. Pressure/Flow Limit Monitoring — Ensures that mea- 
surements stay within predefined operating conditions and 
emergency limits. 

2. Pressure/Flow Deviation Monitoring — Ensures that 
measurements stay within a predefined tolerance of an 
expected operating value. Often, separate deviation limits 
are established for active and inactive conditions and for 
positive and negative deviations. 

3. Pressure/Flow ROC Monitoring — Ensures that any 
rapid measurement change, above a predefined value per 
defined time period, is annunciated. Often, separate ROC 
limits are established for the positive and negative 
directions. 

4. Pressure/Flow ROC Deviation — Modified version of 
the Pressure/Flow ROC Monitoring, that projects 
expected ROC values during transient conditions. Often, 
separate ROC deviation limits are established for the posi- 
tive and negative directions. 

C.7 Acoustic/Negative Pressure Wave 

The acoustic/negative pressure wave technique takes 
advantage of the rarefaction waves produced when the com- 
modity breaches the pipe wall. The leak produces a sudden 
drop in pressure in the pipe at the leak site that generates two 
negative pressure or rarefaction waves, travelling upstream 
and downstream. High response rate/moderate accuracy pres- 



sure transmitters at select locations on the pipeline continu- 
ously measure the fluctuation of the line pressure. A rapid 
pressure drop and recovery will be reported to the central 
facility. At the central facility, the data from all monitored 
sites will be used to determine whether to initiate a CPM 
alarm. 

C.8 Statistical Analysis 

The degree of statistical involvement varies widely with 
the different methods in this classification. In a simple 
approach, statistical limits may be applied to a single parame- 
ter to indicate an operating hydraulic anomaly. Conversely, a 
more sophisticated statistical approach may calculate the 
probability of commodity release against the probability of 
no-commodity release. Pressure and flow inputs that define 
the perimeter of the pipeline are statistically evaluated in real 
time for the presence of patterns associated with a leak. A 
probability value is assigned to whether the event is a com- 
modity release. The analysis can, with suitable instrumenta- 
tion, provide intelligent alarm processing which reduces the 
number of alarms requiring operator analysis. This type of 
CPM methodology does not require an extensive data base 
describing the pipeline. The statistical process control (SPC) 
approach includes statistical analysis on pressure and/or flow. 
SPC techniques can be applied to generate sensitive CPM 
alarm thresholds from empirical data for a select time win- 
dow. A particular method of SPC may use line balance data 
from normal operations to establish historical mean and stan- 
dard deviation. If the mean value of the volume imbalance for 
the evaluated time window increases statistically, the CPM 
system will give a warning. An alarm is generated if the sta- 
tistical changes persist for a certain time period. Also, it can 
correlate the changes in one parameter with those in other 
parameters over short and long time intervals to identify a 
hydraulic anomaly. 
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Figure C-1— CPM System 
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